The present invention relates to computer software and, more particularly, to a license compliance verification system for computer software, licensed material such as copyrighted music and videos, and the like.
When computer software products are licensed to user organizations (customers), the price charged is generally based on the licensed rights conferred. Those rights might be couched in terms of how many computers the product may be executed on, or the aggregate processing power of the computers on which the product will execute, or the particular identities of the computers, or the total number of individuals who may use the product at any given time, or the particular set of named users who may use the product, and so forth.
A user organization with ten computers might license the identical software product, and receive the very same physical media containing the product, as an organization with a single computer, but might pay six or eight times as much. This is considered appropriate, since the larger organization will be deriving more use and value from the software product, and is therefore willing to pay a higher license fee. And if, after initially licensing the software for an initial number of computers (or aggregate power, or number of individuals, etc.), the organization wishes to operate the product on a greater number of computers (or aggregate power, or number of individuals, etc.), the software vendor will want to charge an “upgrade” fee to grant those additional licensed rights. And, increasingly, software licensed for use on Personal Computers is licensed and charged for based on the discrete functions that the user elects to perform, and/or the number of such operations performed (or permitted) within a given time period, such as a month, with extra charges being due if more functions are used or monthly limits exceeded.
It is therefore very important to vendors to try to ensure that licensees of their products do not use them beyond the rights that the licensees have paid for.
Many vendors control the use of their licensed software products via some type of Execution Control Mechanism (ECM). This might take the form of a License Manager (LM). LMs being presently marketed include FLEXlm from Globetrotter, LicensePower/iFOR from Isogon, LUM from IBM, and Sentinel/LM from Rainbow. Alternatively, a software vendor might develop his own vendor-specific ECM, for use only with that vendor's licensed products.
While the above LMs are proprietary, the XSLM standard for LMs was approved in March of 1999 by The OpenGroup (TOG). The standard is expected to encourage the development of XSLM-compliant LMs (XSLM-LMs) from several LM vendors. In particular, Isogon Corporation and IBM are jointly developing an XSLM-LM that will be marketed by the parties under their respective brands.
Licensees of a software product controlled by a particular ECM are obliged to install and operate that ECM on the licensee's computer system or network. (Many vendor-specific ECMs are embedded in the licensed products they control, and do not have to be executed separately.) The ECM accepts passwords or license certificates, supplied by the vendor of the licensed software, that describe the extent of the licensed rights, such as the computers the software may run on (as defined by their serial numbers), the number of concurrent users, the identity of particular authorized users, etc. Typically, when a licensed software product begins its execution, it invokes the ECM, perhaps using an Application Programming Interface (API) defined for this purpose by the vendor of the LM, and supplying identification information including the name of the software product. The ECM determines if there exists a license certificate corresponding to the software product in question, and, if so, whether the licensed rights detailed in the certificate match the circumstances of use. If they do, a “clear-to-proceed” response is returned to the licensed software product. But if they do not—if, for example, the licensed software product is currently executing on a computer whose serial number is not defined in the certificate—the ECM returns an “out-of-compliance” response to the licensed software product, which can take whatever action the vendor of that product has deemed appropriate under that circumstance.
Software vendors who instrument their products to use the services of an ECM can elect to have those products, if they should receive an “out-of-compliance” (OOC) response from the ECM, simply refuse to process further, terminating, perhaps with an explanatory message. (This is known as a “hard stop”.) In this way, vendors are fully protected against misuse of their products.
However, end-user licensees generally regard hard-stops as extremely harsh and unyielding, possibly even constituting unlawful repossession of the software. They take the view that there may be a valid justification for going beyond the rights conferred by the software license. For example if a computer fails, and has to be replaced by another on an emergency basis, any licensed software products whose license is tied to the computer serial number of the original computer will receive an out-of-compliance signal from the ECM if the user attempts to operate them on the replacement computer. Yet the licensee, and probably the vendor as well, might consider this a permitted use. As another example, if a particular employee, to whom a software product is tied by name, is replaced (perhaps, due to illness, only by a temporary worker), the new employee will not be able to use the software product, and therefore may not be able to perform his job duties.
User organizations are typically permitted by their license agreements to replace a computer or an employee with another. But until they formally notify the software vendor of the change, and receive a new license certificate reflecting that change, the ECM will continue interpreting the situation as out-of-compliance, causing (from the user's perspective) inappropriate hard-stops.
Acknowledging these concerns, some vendors do not use hard-stops in their products, relying instead on the strength of the provisions in their license agreements, and the hope that user organizations will not wish to violate the terms of a contract. Vendors may also, in their license agreements, require the right to periodically audit the activities of the licensee to ensure that license terms have been complied with. And some vendors, while continuing to use the services of an ECM for their products, do not employ a hard-stop in out-of-compliance instances, instead allowing the products to continue to operate after issuing a warning or alert that an out-of-compliance situation exists.
Other vendors might employ hard-stops in their products for some or all out-of-compliance conditions but allow users to freely create or modify certificates. This approach, called “customer managed licensing”, gives users the unilateral ability to define certificates embodying additional rights, perhaps any rights they choose, whether or not those rights are actually contained in the applicable license agreement. Thus, the user can always avoid the occurrence of a hard-stop by defining an appropriate certificate, even going beyond the conditions of their license if they feel this is proper or necessary. Some vendors feel that requiring the user to take an overt action such as defining additional rights in a certificate, which can be logged or otherwise captured by the ECM, makes it more difficult for a user to later claim that a product was improperly used “by accident”.
But, in practice, all these protections, aside from a hard-stop, are rather weak. Users tend to be more lenient and forgiving of their own actions than a vendor would wish them to be. Vendors rarely invoke their right to conduct audits, as an audit is an expensive undertaking (for which the vendor would typically have to pay), and is intrusive, disruptive and therefore objectionable to the user organization, who is after all the vendor's client, with whom the vendor often hopes to do future business.
The warnings, modified certificates and other records of non-compliance, even if captured and logged by an LM, do not typically find their way back to the vendor, as this information is mixed together with information about other unrelated activities pertaining to products from other vendors, as well as information about the customer's computer system as a whole. Most customers would regard this as confidential and would not allow it to be released to a particular vendor. And in general, customers are leery of sending any information to vendors without carefully reviewing it beforehand and, at the very least, being aware of anything that might be controversial or wrongly construed by the vendor.
A typical mainframe computer might have 500 software products, licensed from dozens of vendors, and employing multiple license managers. As such, the generation, dissemination and transmittal of compliance information to each vendor can be burdensome, onerous and error-prone.